<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.29
     from name.tnf on 19 December 2010 -->

<TITLE>Name analysis according to scope rules - Scopes Being Properties of Objects</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000" BACKGROUND="gifs/bg.gif">
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0" VALIGN=BOTTOM>
<TR VALIGN=BOTTOM>
<TD WIDTH="160" VALIGN=BOTTOM>
<A HREF="http://eli-project.sourceforge.net/">
<IMG SRC="gifs/elilogo.gif" BORDER=0>
</A>&nbsp;
</TD>
<TD WIDTH="25" VALIGN=BOTTOM>
<img src="gifs/empty.gif" WIDTH=25 HEIGHT=25>
</TD>
<TD ALIGN=LEFT WIDTH="475" VALIGN=BOTTOM>
<A HREF="index.html"><IMG SRC="gifs/title.png" BORDER=0></A>
</TD>
<!-- |DELETE FOR SOURCEFORGE LOGO|
<TD>
<a href="http://sourceforge.net/projects/eli-project">
<img
  src="http://sflogo.sourceforge.net/sflogo.php?group_id=70447&amp;type=13"
  width="120" height="30"
  alt="Get Eli: Translator Construction Made Easy at SourceForge.net.
    Fast, secure and Free Open Source software downloads"/>
</a>
</TD>
|DELETE FOR SOURCEFORGE LOGO| -->
</TR>
</TABLE>

<HR size=1 noshade width=785 align=left>
<TABLE BORDER=0 CELLSPACING=2 CELLPADDING=0>
<TR>
<TD VALIGN=TOP WIDTH="160">
<h4>General Information</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="index.html">Eli: Translator Construction Made Easy</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gindex_1.html#SEC1">Global Index</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="faq_toc.html" >Frequently Asked Questions</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Tutorials</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="EliRefCard_toc.html">Quick Reference Card</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="novice_toc.html">Guide For new Eli Users</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="news_toc.html">Release Notes of Eli</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="nametutorial_toc.html">Tutorial on Name Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="typetutorial_toc.html">Tutorial on Type Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Reference Manuals</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ui_toc.html">User Interface</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="pp_toc.html">Eli products and parameters</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lidoref_toc.html">LIDO Reference Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Libraries</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lib_toc.html">Eli library routines</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="modlib_toc.html">Specification Module Library</a></td></tr>
</table>

<h4>Translation Tasks</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lex_toc.html">Lexical analysis specification</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="syntax_toc.html">Syntactic Analysis Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="comptrees_toc.html">Computation in Trees</a></td></tr>
</table>

<h4>Tools</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lcl_toc.html">LIGA Control Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="show_toc.html">Debugging Information for LIDO</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gorto_toc.html">Graphical ORder TOol</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="fw_toc.html">FunnelWeb User's Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ptg_toc.html">Pattern-based Text Generator</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="deftbl_toc.html">Property Definition Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="oil_toc.html">Operator Identification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="tp_toc.html">Tree Grammar Specification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="clp_toc.html">Command Line Processing</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="cola_toc.html">COLA Options Reference Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="idem_toc.html">Generating Unparsing Code</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="mon_toc.html">Monitoring a Processor's Execution</a> </td></tr>
</table>

<h4>Administration</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="sysadmin_toc.html">System Administration Guide</a> </td></tr>
</table>

<HR WIDTH="100%">
<A HREF="mailto:eli-project-users@lists.sourceforge.net">
<IMG SRC="gifs/button_mail.gif" BORDER=0 ALIGN="left"></A>
<A HREF="index.html"><IMG SRC="gifs/home.gif" BORDER=0 ALIGN="right"></A>

</TD>
<TD VALIGN=TOP WIDTH="25"><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>

<TD VALIGN=TOP WIDTH="600">
<H1>Name analysis according to scope rules</H1>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="name_4.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="name_6.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="name_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
<H1><A NAME="SEC11" HREF="name_toc.html#SEC11">Scopes Being Properties of Objects</A></H1>
<P>
Language constructs like modules, classes, or record types have a body
that is a range. The set of bindings for the components defined
in that range constitutes its scope. 
In an applied context of a module, class, or record identifier
its components may be selected, e.g. in <CODE>m.k</CODE>,
where <CODE>m</CODE> is a module identifier and <CODE>k</CODE> is 
one of its components. These constructs are also called
<EM>qualified names</EM> in some language descriptions.
In order to bind such applied occurrences
of component identifiers in contexts outside their defining range,
the scope of the range is associated as a property to the
key of the module, class, or record identifier.
<P>
This specific task of consistent renaming for component identifiers is often 
closely related to type analysis. If <CODE>v</CODE> in <CODE>v.k</CODE> is a variable
that has a record type, then that type key has the scope of the
record range associated as a property 
(see  <A HREF="type_toc.html">Type Analysis of Type analysis tasks</A>).
<P>
The following four modules extend the basic scope rule modules
(see  <A HREF="name_2.html#SEC2">Basic Scope Rules</A>) by facilities that support scope properties.
How to select one of the modules is explained below.
<P>
<DL COMPACT>
<DT><CODE>ScopeProp</CODE>
<DD>Scope Properties without left-to-right Restrictions (recommended)
<DT><CODE>CScopeProp</CODE>
<DD>Scope Properties C-like (recommended only with CInh)
<DT><CODE>BuScopeProp</CODE>
<DD>Scope Properties C-like analyzed while processing input
</DL>
<P>
The design of scope rules and their description needs careful consideration
if the concept of scopes being properties is involved.
We have to answer some questions on the described language before we 
can decide which of the library modules is to be used:
<P>
It is easily decided that we need the facility of scope properties:
Assume the language has named program objects, say modules, which
consist of a range with definitions of components or members.
Those members are accessible outside their defining range
wherever the name of the module is accessible:
<PRE>
  module m
    { int i;
      float f (); {...}
    }
  m:f();
</PRE>
In this example the module body is a range where the members <CODE>i</CODE> and 
<CODE>f</CODE> are defined. The scope of the range contains bindings for
<CODE>i</CODE> and <CODE>f</CODE>. It is a property of the module <CODE>m</CODE> which is
set in the module definition. The construct <CODE>m:f</CODE> is a qualified name:
A binding for <CODE>f</CODE> is to be found in the scope property of the
qualifying module name <CODE>m</CODE>. The definitions valid in the context of
the qualified name are irrelevant for the binding of <CODE>f</CODE>.
<P>
The same application pattern occurs for example with types that have
components, like record types, structure types, and union types. There 
a component selection is usually qualified with an expression having
such a type rather than with the type identifier itself.
<P>
It is recommended to use the <CODE>ScopeProp</CODE> module for the specification
of such scope patterns. It fits to any of the basic scope rule modules,
Alg-like, C-like, or bottom-up. It does <EM>not</EM> impose any ordering 
restriction that would require the definition of a member to occur before
its qualified use. For example in a language with C-like basic scope rules
the following sequence would be acceptable:
<PRE>
  module m;
  m:f();
  module m
    { int i;
      float f (); {...}
    }
</PRE>
Even if it should be considered erroneous to use the qualified name
<CODE>f</CODE> before its definition, it is recommended to specify
the binding in the described way, and to enforce that restriction by
a check of the related positions.
The same holds for bottom-up basic scope rules. One only has to be aware
that the binding of qualified names is determined <EM>after</EM> the
bottom-up computations.
<P>
There are a few specific reasons where the modules
<CODE>CScopeProp</CODE> or <CODE>BuScopeProp</CODE>, 
the C-like variants of <CODE>ScopeProp</CODE>
are to be used instead: 
<P>
If the basic scope rules are specified C-like using <CODE>BuScope</CODE>
and the binding of qualified names has to be done by bottom-up computations,
then <CODE>BuScopeProp</CODE> is to be used.
<P>
If the basic scope rules are specified C-like using <CODE>CScope</CODE>
and the <CODE>CInh</CODE> module is used to implement the concept of inheritance,
then <CODE>CScopeProp</CODE> is to be used. That is always necessary when
bindings of scope properties are needed to solve the binding of
non-qualified names in ranges where C-like scope rules apply.
As a consequence it is enforced that the definitions of such members
precede their uses.
<P>
The general description of this set of module is given in the section
see  <A HREF="name_5.html#SEC12">Scope Properties without left-to-right Restrictions</A>, the deviations of its variants are described in
see  <A HREF="name_5.html#SEC13">Scope Properties C-like</A>, and see  <A HREF="name_5.html#SEC14">Scope Properties C-like Bottom-Up</A>.
<P>
<A NAME="IDX138"></A>
<H2><A NAME="SEC12" HREF="name_toc.html#SEC12">Scope Properties without left-to-right Restrictions</A></H2>
<P>
This module <CODE>ScopeProp</CODE> implements consistent renaming of identifiers
using scopes which are properties associated to object keys.
The module computations ensure that scope properties are associated
and bindings are made before they are accessed. 
This strategy fits to Algol-like scope rules, and to C-like scope rules
if qualified names may be used before their definition.
<P>
The module is instantiated by
<PRE>
   $/Name/ScopeProp.gnrc+instance=NAME +referto=KEY :inst
</PRE>
<P>
It is required that a
basic scope rule module is instantiated with the same generic parameters
<CODE>+instance=NAME</CODE> and <CODE>+referto=KEY</CODE>.
<A NAME="IDX139"></A>
<P>
Each of the modules introduces a <CODE>PDL</CODE> property named 
<CODE>NAMEScope</CODE>
where <CODE>NAME</CODE> is the value of the <CODE>instance</CODE> parameter.
<P>
The module provide <CODE>.lido</CODE> specifications for the
computational roles
<CODE>NAMEExportRange</CODE>,
<CODE>NAMEQualIdUse</CODE>, and
<CODE>NAMEChkQualIdUse</CODE>:
<A NAME="IDX140"></A>
<A NAME="IDX141"></A>
<P>
<CODE>NAMEExportRange</CODE>
is a <CODE>NAMERangeScope</CODE> the scope of which is associated as a value of 
the <CODE>NAMEScope</CODE> property to the value of the attribute 
<CODE>KEYScopeKey</CODE>. All local definitions are bound in this scope.
The scope may be used to bind 
qualified names (<CODE>NAMEQualIdUse</CODE>), or to provide the source for
inheritance. Such uses may occur outside as well as inside of 
that <CODE>NAMEExportRange</CODE>. 
A user computation is required to set the attribute 
<CODE>THIS.KEYScopeKey</CODE>. The scope will be set as a value of its 
property <CODE>NAMEScope</CODE>. 
This role is typically inherited by a grammar symbol that represents
the body of a module, of a class, or of a record type.
The <CODE>KEYScopeKey</CODE> attribute is then set to the key representing
the module, class, or record type.
<A NAME="IDX142"></A>
<A NAME="IDX143"></A>
<A NAME="IDX144"></A>
<P>
<CODE>NAMEQualIdUse</CODE> is inherited by an applied occurrence
of a qualified identifier. Its binding is looked up 
in a scope that is obtained
as a <CODE>NAMEScope</CODE> property from the attribute <CODE>THIS.NAMEScopeKey</CODE>.
A computation of <CODE>INH.NAMEScopeKey</CODE> has to be provided.
The obtained scope is available in the attribute
<CODE>THIS.NAMEScope</CODE>, e.g. to support a check whether the qualification is
correct. Alternatively, a user computation may compute <CODE>THIS.NAMEScope</CODE>
instead of <CODE>THIS.NAMEScopeKey</CODE>.
This role is typically inherited by a grammar symbol that represents
a qualified identifier occurrence like <CODE>sleep</CODE> in <CODE>Thread.sleep</CODE> or 
<CODE>push</CODE> in <CODE>st.push</CODE>. 
The binding may be looked up in a scope associated
to <CODE>Thread</CODE> or to the type of <CODE>st</CODE>, for example.
<A NAME="IDX145"></A>
<P>
<CODE>NAMEChkQualIdUse</CODE> can be inherited together with <CODE>NAMEQualIdUse</CODE>.
It causes a message to be given, if no binding is found for the identifier.
<A NAME="IDX146"></A>
<A NAME="IDX147"></A>
<P>
Computations of this modules also establish attributes 
<CODE>NAMEGotVisibleScopePropNest</CODE>, <CODE>NAMEGotVisibleKeys</CODE>, 
and <CODE>NAMEGotVisibleKeysNest</CODE>
of including
<CODE>NAMERangeScope</CODE>s and <CODE>NAMERootScope</CODE>.
They are used in modules computations which access the 
<CODE>NAMEScope</CODE> property or which look up bindings in those
scopes. In general these attributes need not be considered in in user
computations.
<P>
We demonstrate the use of these facilities by extending the language
of our running example by module declarations and access of
module components. (For a complete example see the Tutorial on Name Analysis.)
The notation is specified by the following
two concrete productions:
<P>
<PRE>
   Declaration:    'module' DefIdent ModBlock ';'.
   ModBlock:       Compound.
   Operand:        ModUseIdent '::' QualIdent.
   ModUseIdent:    Ident.
   QualIdent:      Ident.
</PRE>
<P>
The symbols inherit the roles provided by the scope property module
as described above:
<P>
<PRE>
   SYMBOL ModBlock INHERITS ExportRange END;

   RULE: Declaration ::= 'module' DefIdent ModBlock ';' COMPUTE
         ModBlock.ScopeKey = DefIdent.Key;
   END;
</PRE>
<P>
In the context of the module declaration it is specified that
the scope of the module body is to be associated to the key of the
module identifier.
<P>
In the context of a selection the scope is specified
in which the selected component is to be bound.
It is accessed from the key of the module identifier.
Module computations establish dependences such that
all scope properties are associated before they are accessed here:
<P>
<PRE>
   SYMBOL ModUseIdent INHERITS
          IdUseEnv, ChkIdUse, IdentOcc
   END;

   SYMBOL QualIdent   INHERITS
          QualIdUse, ChkQualIdUse, IdentOcc
   END;
   RULE: Expression  ::= ModUseIdent '::' QualIdent COMPUTE
         QualIdent.ScopeKey = ModUseIdent.Key;
   END;
</PRE>
<P>
In order to make sure that the it is really a module identifier to
which the selection is applied we specify the following check
<P>
<PRE>
   RULE: Expression  ::= ModUseIdent '::' QualIdent COMPUTE
     IF (AND (NE (QualIdent.ScopeKey, NoKey),
              EQ (QualIdent.Scope, NoEnv)),
     message (FATAL, CatStrInd ("module identifier required: ",
                                ModUseIdent.Sym), 
              0, COORDREF));
   END;
</PRE>
<P>
The message is only issued if the identifier is defined but
does not have a scope property.
<P>
(The <CODE>Strings</CODE> module is used
to compose the message text 
(see  <A HREF="problems_2.html#SEC2">String Concatenation of Solutions of common problems</A>).)
<P>
<A NAME="IDX148"></A>
<H2><A NAME="SEC13" HREF="name_toc.html#SEC13">Scope Properties C-like</A></H2>
<P>
This module implements consistent renaming of identifiers
using scopes which are properties associated to object keys.
The module computations establish bindings, lookup names,
associate scope properties, and lookup qualified names
in left-to-right depth-first order. 
It imposes the strong requirement that a
qualified name, for example the <CODE>f</CODE> in <CODE>m.f</CODE>,
may not preceed its definition.
<P>
It is recommended to use this module only if it is needed as
a companion of the module <CODE>CInh</CODE>. Otherwise <CODE>ScopeProp</CODE>
should be used (see  <A HREF="name_5.html#SEC11">Scopes Being Properties of Objects</A>).
<P>
The module is instantiated by
<PRE>
   $/Name/CScopeProp.gnrc+instance=NAME +referto=KEY :inst
</PRE>
<P>
Using this module requires that the module <CODE>CScope</CODE> is instantiated
with the same values of the generic parameters.
<A NAME="IDX149"></A>
<A NAME="IDX150"></A>
<P>
The module provides a <CODE>PDL</CODE> property named <CODE>NAMEScope</CODE>
and the computational roles 
<CODE>NAMEExportRange</CODE>,
<CODE>NAMEQualIdUse</CODE>, and <CODE>NAMEChkQualIdUse</CODE> as
described in see  <A HREF="name_5.html#SEC12">Scope Properties without left-to-right Restrictions</A>.
<P>
All computations of this module follow strictly C-like scope rules,
i.e. binding of identifier occurrences, association of scope properties,
and access of scope properties are done in left-to-right 
depth-first order.
<A NAME="IDX151"></A>
<A NAME="IDX152"></A>
<P>
Calls of <CODE>GetNAMEScope</CODE> in a user computation
do not need a specific precondition if they depend on a key attribute
of a context which is to the right of the context where the
property is set. That is usually true for situations where
the module role <CODE>NAMEQualIdUse</CODE> is used.
Only if a particular computation is to depend on the fact that
all scope properties of the program are associated,
it may depend on <CODE>INCLUDING NAMERootScope.NAMEGotScopeProp</CODE>.
<P>
<A NAME="IDX154"></A>
<A NAME="IDX153"></A>
<H2><A NAME="SEC14" HREF="name_toc.html#SEC14">Scope Properties C-like Bottom-Up</A></H2>
<P>
This module implements consistent renaming of identifiers
using scopes which are properties associated to object keys.
The module computations ensure that scope properties are associated
and accessed in left-to-right depth-first order.
It imposes the strong requirement that a
qualified name, for example the <CODE>f</CODE> in <CODE>m.f</CODE>,
may not preceed its definition.
<P>
It is recommended to use this module only if qualified identifiers
have to be bound in the bottom-up phase, or if the module is needed as
a companion of the module <CODE>BuInh</CODE>. Otherwise <CODE>ScopeProp</CODE>
should be used (see  <A HREF="name_5.html#SEC11">Scopes Being Properties of Objects</A>).
<P>
The computations provided by this module are 
executed while reading the input.
<P>
The module is instantiated by
<PRE>
   $/Name/BuScopeProp.gnrc+instance=NAME +referto=KEY :inst
</PRE>
<P>
Using this module requires that the module <CODE>BuScope</CODE> is instantiated
with the same values of the generic parameters.
<P>
The module provides a <CODE>PDL</CODE> property named <CODE>NAMEScope</CODE>
and the computational roles 
<BR> <CODE>NAMEIdSetScopeProp</CODE>,
<CODE>NAMEIdGetScopeProp</CODE>, and <CODE>NAMEQualIdUse</CODE>.
A role 
<BR> <CODE>NAMERangeScopeProp</CODE> is NOT provided;
<CODE>NAMERangeScope</CODE> has to be used instead.
<P>
Note: The role names of the module <CODE>ScopeProp</CODE> as 
<CODE>NAMEExportRange</CODE>, <CODE>QualIdUse</CODE> and <CODE>ChkQualIdUse</CODE>
do not apply here.
<P>
All computations of this module follow strictly C-like scope rules,
i.e. binding of identifier occurrences, association of scope properties,
and access of scope properties are done in left-to-right
depth-first order.
<A NAME="IDX155"></A>
<A NAME="IDX156"></A>
<A NAME="IDX157"></A>
<A NAME="IDX158"></A>
<A NAME="IDX159"></A>
<P>
As a consequence of bottom-up computation the value of a key can
not be propagated by an upper computation to the range symbol.
Hence, if the defining identifier occurrence precedes the range,
the scope has to be created by the role <CODE>NAMECreateNewScope</CODE>
(see  <A HREF="name_2.html#SEC5">C-like Basic Scope Rules Computed Bottom-Up</A>) and associated to the key in the identifier context
using the role <CODE>NAMEIdSetScopeProp</CODE>.
<P>
The role that opens the range scope (<CODE>NAMEOpenNewScope</CODE>,
see  <A HREF="name_2.html#SEC5">C-like Basic Scope Rules Computed Bottom-Up</A>) may also be associated to that identifier context,
avoiding an additional symbol that derives to empty.
<P>
The range symbol has the role <CODE>NAMERangeScope</CODE>.
<P>
The module declaration of our example then reads:
<PRE>
   RULE: Declaration ::= 'module' ModDefIdent Block ';' END;

   SYMBOL ModDefIdent INHERITS
          CreateNewScope, OpenNewScope, IdSetScopeProp,
          IdDefScope, IdentOcc
   COMPUTE
     SYNT.OpenPrecond = SYNT.Key;
   END;
</PRE>
<P>
<CODE>NAMEOpenPrecond</CODE> is specified to depend on the key attribute
to ensure that the identifier is bound in the enclosing environment
before the environment of the module range is opened.
<A NAME="IDX160"></A>
<A NAME="IDX161"></A>
<A NAME="IDX162"></A>
<A NAME="IDX163"></A>
<P>
In component selections the scope property needs to be propagated
from the context that provides it to the selector context.
The module role <CODE>NAMEGetScopeProp</CODE> accesses the scope
from the key specified by <CODE>KEYScopeKey</CODE> and assigns 
it to a variable. It is used at the selector context right of it
by the role <CODE>NAMEQualIdUse</CODE>.
<P>
Hence, in our running example the selection is specified
as follows:
<P>
<PRE>
   RULE: Expression  ::= ModUseIdent '::' QualIdent END;

   SYMBOL ModUseIdent INHERITS 
          GetScopeProp, IdUseEnv, ChkIdUse, IdentOcc
   COMPUTE
     SYNT.ScopeKey = THIS.Key;
   END;

   SYMBOL QualIdent   INHERITS 
          QualIdUse, ChkIdUse, IdentOcc
   END;
</PRE>
<P>
If we had a typed record expression instead of the module identifier
to select from, <CODE>ScopeKey</CODE> would be set to the type key
instead of the module key.
<P>
<A NAME="IDX164"></A>
<HR size=1 noshade width=600 align=left>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="name_4.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="name_6.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="name_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
</TD>
</TR>
</TABLE>

</BODY></HTML>
